The term “Web services” is often used to describe the software systems and interfaces through which services are made available to Web users and Web-connected programs. Several examples of Web services include online computing and data storage services, Web site use analysis, Web search engines, online shopping, insurance quotes, stock trading, travel reservations, online auctioning, managing blogs, tracking packages, viewing maps, accessing e-mail, etc.
The exchange of messages is what enables a Web service to be coordinated between multiple partners. For example, the W3C organization has described a general message format in which Web service provider's computer systems can interact (e.g., sending messages enclosed in simple object access protocol (“SOAP”) envelopes over HTTP). The W3C organization has defined the message format standards incorporated into some of the most common Web services architectures.
The use of Web services has become more common due in part to improved development tools that make it easier to create and enter Web services partnerships. A well-known approach for developing Web services partnerships is to use the Business Process Execution Language (“BPEL”). BPEL provides an XML-based computer language that allows users to define rules to integrate Web services partnerships. The BPEL process defines how the Web services interoperate (e.g., the BPEL process defines what messages should be sent to which partner, etc.) without modifying the actual services themselves. The partner Web services themselves are external to the BPEL process. To illustrate, suppose a BPEL process is developed to integrate a multi-party transaction between an online store, a credit card company, and a shipping company. In this example, a user accesses the online store to find and purchase a book. The user navigates the online store's Website until he finds the book he wants to buy. He then selects the item for purchase, and, when prompted, submits credit card information to the online store. When the user submits the credit card information, a BPEL process coordinates the flow of information from the online store to the credit card company. Accordingly, the BPEL process defines the format for all purchase order messages sent from the online store to the credit card company. Hence, when the user submits his credit card information a message is created according to the format described by the BPEL process and then sent to the credit card company. The credit card company receives the message, extracts whatever information it needs (e.g., the user's identity, the amount in question, and other information), and returns a result message. The BPEL process ensures that the result message is in the proper format. Assuming that the credit card transaction was approved, the BPEL process then coordinates the online store's interaction with the shipping company.
As with virtually every software development project, it would be useful to test a BPEL process before deploying it. Currently, to test a BPEL process, a partner Web service has to be available to receive and respond to requests. This creates several problems. For example, in many cases the partner Web service has yet to be developed. In other cases, the partner Web service is simply unavailable to be used in a development environment (e.g., it is a live production Web site and using it as a test target would negatively affect its performance).
As a result, alternative testing solutions have been developed. The most common solution has been to create testing Web sites that simulate a partner Web service. For example, suppose a BPEL process is developed to coordinate the interaction of a travel reservation Web site with an airline reservation database. The travel reservation Web site provides users with flight schedule information retrieved from the airline reservation database. Conventionally, to test the BPEL process, the developers have to create and populate a testing database and Website that simulate the airline reservation database. The BPEL process is then run against this test airline reservation database.
The problem with this approach is that it is a time consuming and resource expensive way of doing testing. Designing and setting up a testing website with the proper data set is not a trivial process. It requires a significant investment of time and often money to complete. Those costs only get greater as the number of partner Web services being coordinated grows. Moreover, in some instances, it may be difficult to simulate a website because the developers may not know exactly how the partner Web site processes messages.
Given these constraints, there is a need for tools and techniques to test BPEL processes without the need for the partner Web services to be available.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.